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REAL TIME DEBUG SUPPORT FOR A DMA DEVICE AND METHOD 

THEREOF 

Field of the Invention 
The present invention relates to a data processing system, and more 
particularly, to test and debug features in a data processing system. 

Related Art 

Data processing systems have one or more buses that function as a 
communication highway for the system. The one or more buses function to transfer 
address, data and/or control information during time periods defined by clock cycles. 
It is well documented in the literature to apply various techniques to test the 
functionality of the circuitry within a data processing system and to check and verify 
the functionality of executing software, known as software program debugging. A 
critical component in test methodologies is to obtain external visibility for portions of 
a data processing system, such as the contents of registers and the results of system 
operation. Test and debug equipment external to a data processing system is used to 
monitor values of address, data and control information being transferred by the 
system's bus or buses. 

Typical data processing systems use a technique known as a direct memory 
access (DMA). Using direct memory access, information can be directly transferred 
between input/output devices and a memory with only minimal involvement by a 
central processing unit (CPU). Thus a DMA controller functions to transfer a stream 
of information from a source in a data processing system to a destination. 

System-on-a-chip (SOC) designs are typically composed of multiple devices 
and buses that are capable of generating debug messages using real-time techniques. 
For example, an BEEE standard known as IEEE ISTO5001, or the Nexus debug 
standard, is an established real-time debug standard that supports real-time debug 
message generation by multiple on-chip devices. The Nexus debug standard specifies 
a mechanism for identifying to an external trace reconstruction tool a predetermined 
operating condition within the system. However, this debug information is typically 
limited to the monitoring of information that is read or written to a system memory 
and to the tracking of changes of execution flow of software being executed such as a 
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number of sequential instructions executed since a last taken branch. The present 
debug processor capability provides a very limited amount of information regarding 
DMA activity. 

Brief Description of the Drawings 

The present invention is illustrated by way of example and not limited by the 
accompanying figures, in which like references indicate similar elements, and in 
which: 

FIG. 1 illustrates in block diagram form a data processing system in 
accordance with one embodiment of the present invention; 

FIG. 2 illustrates in block diagram form an alternative data processing system 
in accordance with the present invention; 

FIG. 3 illustrates in timing diagram form information transfers of a channel as 
a function of time; 

FIG. 4 illustrates in diagrammatic form a format of a first transfer message; 
FIG. 5 illustrates in diagrammatic form a format of a second transfer message; 
FIG. 6 illustrates in diagrammatic form a format of a third transfer message; 
FIG. 7 illustrates in diagrammatic form a format of a fourth transfer message; 
FIG. 8 illustrates in diagrammatic form a format of a fifth transfer message; 
FIG. 9 illustrates in layout form a control register for DMA messaging; and 
FIG. 10 illustrates in layout form a control register for periodic status 
messaging. 

Skilled artisans appreciate that elements in the figures are illustrated for 
simplicity and clarity and have not necessarily been drawn to scale. For example, the 
dimensions of some of the elements in the figures may be exaggerated relative to 
other elements to help improve the understanding of the embodiments of the present 
invention. 

Detailed Description of the Drawings 

As used herein, the term "bus" is used to refer to a plurality of signals or 
conductors which may be used to transfer one or more various types of information, 
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such as data, addresses, control, or status. The terms "assert" and "negate" are used 
when referring to the rendering of a signal, bit, or similar apparatus into its logically 
true or logically false state, respectively. If the logically true state is a logic level one, 
the logically false state is a logic level zero. Furthermore, the memory described 
herein may be any type of memory, such as, for example, a read-only memory 
(ROM), a random access memory (RAM), static random access memory (SRAM), 
non-volatile memory (e.g. Flash), and MRAM, etc. 

FIG. 1 illustrates, in block diagram form, a data processing system 10 that 
provides real-time DMA-specific debug functionality. Data processing system 10 
permits a class of real-time debug message types that are specific to DMA bus 
masters and which indicate critical status parameters. Data processing system 10 
therefore provides an improved source of debug information via real-time messages 
for DMA units. 

In one form, a multi-conductor system bus 12 is provided for communicating 
between all system devices. A processor 14 is bidirectionally connected to the system 
bus 12. While bidirectional buses described herein are indicated by hash mark to be 
multiple conductor buses, it should also be readily understood that single conductor 
buses and/or multiple unidirectional buses may also be implemented. Also 
bidirectionally connected to system bus 12 is a DMA controller device 16, a memory 
18, a memory 20, a peripheral 22, a peripheral 24, a debug module 26 and a bus 
arbiter 28. Debug module 26 provides at an output thereof a debug port for providing 
debug information. Each of the DMA controller device 16 and the processor 14 has 
an output for providing a multiple bit status signal to debug module 26. Each of 
processor 14 and DMA controller device 16 respectively has a multiple bit 
bidirectional bus coupled to the bus arbiter 28. An output of peripheral 22 is 
connected to DMA controller device 16 for providing a DMA request signal labeled 
DMA_REQ. Similarly, an output of peripheral 24 is connected to DMA controller 
device 16 for providing a DMA request signal labeled DMA_REQ. While the 
systems units described herein are illustrated in FIG. 1 as being directly connected to 
the system bus 12, it should be understood that coupling circuitry (not shown), such as 
drivers, buffers, etc. may be between the system bus 12 and the illustrated system 
units. 
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In operation, data processing system 10 executes a predetermined instruction 
set using processor 14. Information is stored in one of memory 18 or memory 20. It 
should be understood that only one memory or any other number of memories may be 
implemented and connected to system bus 12. DMA controller device 16 functions to 
control the transfer of a stream of information from a source within the data 
processing system 10 to a destination within the data processing system 10. The 
information within data processing system 10 is communicated within a channel 
which is a stream associated between a source and a destination. Peripherals within 
data processing system 10 such as peripheral 22 or peripheral 24 may be any of a 
variety of circuit devices, but typically will function as slaves to system bus 12 by not 
requesting bus arbiter 28 for control of the system bus 12. Regardless of the type of 
device the peripherals are, the peripherals form part of the system memory mapping. 
Bus arbiter 28 functions to arbitrate control of system bus 12 between any devices 
within data processing system 10 that request control of system bus 12. Any of 
numerous conventional arbitration algorithms may be used to implement data 
processing system 10. Debug module 26 functions to provide one or more real-time 
debug messages associated with the DMA controller device 16 as described below. In 
other words, debug module 26 monitors the DMA controller device 16 by receiving 
status signals from both the DMA controller device 16 and processor 14 and generates 
real-time debug messages as described below for output to the debug port. 

Illustrated in FIG. 2 is an alternative embodiment of the configuration of data 
processing system 10 of FIG. 1. A system bus 30 is bidirectionally connected to a 
DMA controller 44 and to a predetermined number of other system units such as 
system unit 40 and system unit 42. System unit 40 and system unit 42 may be any 
type of bus master or bus slave. Each of system unit 40, DMA controller 44 and 
system unit 42 is respectively bidirectionally coupled to a debug module 32, a debug 
module 34 and a debug module 36. An output of each of debug module 32, debug 
module 34 and debug module 36 is connected to debug port logic 38. The debug port 
logic 38 provides a debug port for providing real-time debug messages. As indicated 
by the dotted lines in FIG. 2, any number of debug modules and system units may be 
coupled between the system bus 30 and the debug port logic 38. 

In an alternative form, the functionality of a debug module is divided in a 
manner to assign a debug module for each system unit that is coupled to system bus 
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30, including the DMA controller 44. The debug port logic 38 receives messages 
from each of debug module 32, debug module 34 and debug module 36 and provides 
the messages at the debug port logic. In one form, the logic of debug port logic 38 is 
configured to provide debug messages on a time sequential basis in which the 
messages are output in the order in which they are received from the various debug 
modules. However, other logic configurations may be used to implement other 
ordering of the debug outputs. 

Illustrated in FIG. 3 is a timing diagram that illustrates transfer activity on a 
channel, designated as channel X, within either system embodiment of FIG. 1 or FIG. 
2. Assume that channel X is a predetermined illustrative data stream within either 
system embodiment associated with a source and a destination. Each of DMA 
controller device 16 and DMA controller 44 is configured to support multiple 
channels for transferring streams of information from sources to destinations. 
Transfers within a channel are generated upon receiving a DMA request signal, such 
as DMA_REQ, from either a source or a destination device. In the FIG. 3 example, 
there are three separate requests illustrated. Each request has a latency associated 
therewith such as latency 50 associated with the first request, latency 52 associated 
with the second request and latency 54 associated with the third request. The length 
of each latency differs due to several system factors, such as the current priority of the 
DMA controller device 16, as determined by bus arbiter 28, and the priority of the 
channel X, as determined by operation of the DMA controller device 16. This latency 
is a system characteristic that is desired to be known external to the system and 
without interrupting the system. 

The transfer of streams of information continues until a certain number of 
bytes of data have been transferred per request. In the illustrated form of FIG. 3, 
assume that each of DMA controller device 16 and DMA controller 44 transfers N 
bytes of information, where N is an integer, per request. For example, transfer 60, 
transfer 62 and transfer 64 occur in response to three separate and sequential channel 
requests. It should be noted that a transfer may be interrupted, such as interrupt 
period 66 associated with transfer 62. The interrupt period 66 may result from a 
number of system factors, such as a change in bus mastership as determined by bus 
arbiter 28. Each transfer of N bytes is referred to as either an "iteration" or a "minor 
loop iteration". A number of minor loop iterations are executed within a "major loop 
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iteration". It should be noted that the use of the term 'iteration' does not imply or 
require a repetition of the same minor loop or major loop transfer. Rather, iteration in 
this context refers to the fact that for any channel, such as channel X of FIG. 3, 
transfer activity is common and therefore multiple successive transfers occur. In the 
FIG. 3 example there are three minor loop iterations, minor loop iteration 59, minor 
loop iteration 61 and minor loop iteration 63, within major loop iteration 65. The 
described channel operation therefore may be considered to be a two-deep nested 
transfer operation where the two levels of nesting are major loops and minor loops. It 
should be understood that any number of minor loop iterations may exist as noted by 
the dotted break in the channel request signal. After completion of a minor loop 
iteration, control of the system bus 12 may be transferred to a higher priority channel 
having a pending request. Alternatively a triggering event may be generated to trigger 
another channel to begin a minor loop iteration. Control of the system bus 12 may 
also be transferred at the end of a major loop iteration. 

In order to optimize overall system operation, external visibility of various 
aspects of the DMA activity as the system executes is very important. Therefore, 
there is provided herein a set of real-time trace messages related to DMA activity. 

Illustrated in FIG. 4 is a first real-time DMA controller message that identifies 
a start of a first transfer, such as the first transfer of major loop iteration 65 of FIG. 3. 
The first transfer message is illustrated having five fields with two of the fields being 
optional. A first field is identified as a Type code (TCODE) field that identifies the 
type or function of the message. By way of example only, the six bit TCODE value 
of 1 101 1 1 is selected to identify the message as a "start of a first transfer" message. 
A second field is a channel identification (Channel ID) field that, in one form, is from 
four to eight bits in length and informs what channel or type of channel the message is 
associated with. A third field is a channel status field and may be anywhere from one 
to eight bits in length, by way of example only. Examples of channel status include 
the priority of the channel at the beginning of the first transfer, a utilization factor (i.e. 
percent of utilization) of the channel, whether a transfer error for the channel has 
previously occurred, and numerous other status or informative detail. A fourth field 
that is optional is a transfer count that signifies how much information the channel 
will transfer. This field may contain transfer count information for each minor loop 
iteration associated with the channel and/or may contain transfer count information 
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for a major loop iteration associated with the channel. As an example only, the 
transfer count field may be from eight to sixty-four bits in length, but other bit lengths 
may be used. A fifth field that is also optional is a transfer service latency. The 
transfer service latency identifies how long in time from the initial channel request it 
takes to begin transfer activity. In other words, the value in this field is an interrupt 
latency associated with a first transfer, such as latency 50. The value in this field may 
be measured by using a counter (not shown) that may be in the debug module 26 or 
elsewhere to count the time period associated with latency 50. In one form, the 
transfer service latency field may be from eight to sixty-four bits in length, but other 
bit lengths may be used. 

Illustrated in FIG. 5 is a second real-time DMA controller message that 
identifies a start of a minor loop iteration, such as any of minor loop iterations 59, 61 
and 63 of FIG. 3. This second transfer message is illustrated having five fields with 
two of the fields being optional. A first field is the Type code (TCODE) field that 
identifies the message as a 'start of minor loop iteration' message. For exemplary 
purposes only, the Type code is illustrated as 1 1 1000 but other values and bit lengths 
may be used. A second field is a channel identification (ED.) field that identifies the 
channel associated with the start of the minor loop iteration. A third field is a channel 
status field that identifies a status parameter or parameters of the channel, such as the 
status information described above for the first message. A fourth field is a transfer 
count for identifying how much information the channel will transfer as described 
above for the transfer count field of the first message. A fifth field is a transfer 
service latency field that identifies the latency, such as latency 50, latency 52 or 
latency 54. Again, the bit lengths that are provided for each field are by way of 
example only. 

Illustrated in FIG. 6 is a third real-time DMA controller message that 
identifies an end of a minor loop iteration, such as any of minor loop iterations 59, 61 
and 63 of FIG. 3. This third transfer message is illustrated having five fields with two 
of the fields being optional. A first field is the Type code (TCODE) field that 
identifies the message as an 'end of minor loop iteration' message. For exemplary 
purposes only, the Type code is illustrated as 111001 but other values and bit lengths 
may be used. A second field is a channel identification (ID.) field that identifies the 
channel associated with the end of the minor loop iteration. A third field is a channel 
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status field that identifies a status parameter or parameters of the channel, such as the 
status information described above for the first message. A fourth field is an iteration 
count for identifying which minor loop iteration is presently being transferred on the 
system bus. A fifth field is an iteration interval which is a count value of how long in 
time the minor loop iteration lasted. A counter (not shown) located anywhere in the 
system may be used, but preferably the counter is within the debug module or in close 
proximity thereto. Again, the bit lengths that are provided for each field are by way 
of example only. Debug module 26 may also be configured so that the third transfer 
message may be generated even though an entire minor loop does not fully complete 
normally due to a transfer error. 

Illustrated in FIG. 7 is a fourth real-time DMA controller message that 
identifies completion of a major loop iteration, such as major loop iteration 65 of FIG. 
3. This fourth transfer message is illustrated having five fields with two of the fields 
being optional. A first field is the Type code (TCODE) field that identifies the 
message as an 'end of a major loop iteration' message. For exemplary purposes only, 
the Type code is illustrated as 1 1 1010 but other values and bit lengths may be used. 
A second field is a channel identification (ID.) field that identifies the channel 
associated with the end of the major loop iteration. A third field is a channel status 
field that identifies a status parameter or parameters of the channel, such as the status 
information described above for the first message. A fourth field is a transfer count 
for identifying how much information the channel has transferred as described above 
for the transfer count field of the first message. A fifth field is a transfer interval field 
which is a count value of how long in time the major loop iteration lasted. A counter 
(not shown) located anywhere in the system may be used, but preferably the counter 
is within the debug module 26 or in close proximity thereto. Again, the bit lengths 
that are provided for each field are by way of example only. Debug module 26 may 
also be configured so that the fourth transfer message may be generated even though 
an entire major loop does not fully complete normally due to a transfer error. 

Illustrated in FIG. 8 is a fifth real-time DMA controller message that provides 
the status of an identified channel on a periodic basis. This periodic messaging 
functions to provide one or more status criteria of the identified channel. This fifth 
transfer message is illustrated having four fields with one of the fields being optional. 
A first field is the Type code (TCODE) field that identifies the message as a 'periodic 
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status' message. For exemplary purposes only, the Type code is illustrated as 1 1 101 1 
but other values and bit lengths may be used. A second field is a channel 
identification (ID.) field that identifies the channel associated with the status 
information being provided. A third field is a channel status field that identifies a 
status parameter or parameters of the channel, such as the status information 
described above in connection with the discussion of the first message. A fourth field 
is a current transfer count for identifying how far the current transfer has progressed at 
the point in time that the status relates to. Again, the bit lengths that are provided for 
each field are by way of example only. Periodic status messages may be used to 
determine the relative progress of channels in the system and to allow for 
modification of channel priorities and bus master priorities of the DMA channels. In 
order for periodic status messages to be generated, the function is enabled by 
programmable control of a register to be described below. When the function is 
enabled, the timing of when the periodic status messages are provided is 
implementation specific. Periodic status messages may be generated whenever a 
predetermined or predefined number of system clock or bus cycles have occurred. 
Alternatively, periodic status messages may be generated on a fixed period as 
determined by specific hardware wiring in the system. 

Illustrated in FIG. 9 is a control register 70 for one DMA channel. Control 
register 70 has, in exemplary form only, five bits that enable or disable eight five 
DMA real-time messages, and four bits that enable or disable generation of 
watchpoint triggers. In one form, control registers for various DMA channels, each 
being similar to control register 70, are provided and located within the debug module 
26. Control register 70 is for a DMA channel designated as channel "CH0". A 
description of the control bit functions for any channel, designated as channel x, CHx, 
is immediately below control register 70. A first bit, bit 0, of control register 70 
enables the periodic status message function. When bit 0 has a logic one value 
asserted, debug module 26 will generate periodic status messages having the format 
as illustrated in FIG. 8. In a similar manner, bits five, six, seven and eight of control 
register 70 enable or disable the messages of FIGs. 7, 6, 5 and 4 respectively. In 
addition to the DMA messages of FIGs. 4-8, control register 70 functions to enable 
the triggering of watchpoints for analysis external to data processing system 10. As 
used herein, the term "watchpoint" refers to the monitoring of a predetermined 



Page 9 



SC13158TH 



internal system event and the signaling or indication when such internal system event 
occurs. Bits 1, 2, 3 and 4 of control register 70 are associated with the enabling of 
watchpoint functions. When these watchpoints are enabled, an indication is provided 
by debug module 26 to the debug port that the associated function occurred, as 
opposed to indicating when in time the event occurred. For example, the SOTWTE 
bit enables the function of determining the start of a transfer in the associated channel 
and asserting a signal or providing a message at the debug port if the transfer occurs. 
The other watchpoint bits provided in FIG. 9 function to indicate that a start of an 
iteration (either minor loop or major loop can be defined) has occurred (bit 3), that an 
end of an iteration (either minor loop or major loop) has occurred (bit 2), and that an 
end of a transfer (either minor loop or major loop) has occurred (bit 1). The selective 
use of the watchpoint functions can be used to enable other debug functions. For 
example, an "End of Transfer" watchpoint may be used within data processing system 
10 to trigger other debug functionality associated with system unit 40, system unit 42, 
processor 14 or any other desired function within data processing system 10. The 
functionality of control register 70 may be expanded or reduced from that illustrated 
in FIG. 9 depending upon a desired application requirement. Control register 70 may 
also be located in other areas of data processing system 10 than within debug module 
26. 

Illustrated in FIG. 10 is a periodic status messaging control register 80 having 
fields for each of a desired number of channels of the DMA controller device 16. In 
the illustrated form four channels are provided and thirty-two bits assigned, but any 
number of channels and bits may be used. In the first channel field, designated CH0, 
the digital value stored therein controls the rate that periodic status messages are 
generated by debug module 26. Therefore, the periodic status messaging control 
register 80 functions to permit a programmable and independent reporting rate for 
each channel to be created. 

By now it should be appreciated that there has been provided a real-time 
debug support method and structure that provides information in the form of messages 
that is specific to DMA operating parameters. Included within the DMA operating 
parameter information is knowing when a DMA transfer begins or ends, knowing a 
point in time when each of minor loop iteration transfers begin and end, knowing a 
point in time when a major loop iteration begins and ends, knowing the periodic status 
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of predetermined DMA channels, and knowing how much latency is associated is 
associated with each DMA channel request. The DMA debug messages described 
herein are generated based on existing signals within the DMA controller device 16 
and are generated on a real-time basis so that no interruption in the operation of either 
the DMA controller device 16 or the processor 14 occurs. By having external access 
to the information which is contained in the DMA messages described herein, an 
improved level of system-on-chip (SOC) debug, verification and performance can be 
readily obtained. 

In one form there has been provided a system and method of operation thereof 
having a communication bus and a direct memory access (DMA) device coupled to 
the communication bus. The direct memory access device controls channels of 
information, each channel of the channels of information transferring information 
from a source to a destination in the system via a channel transfer. Debug control 
circuitry is coupled to the DMA device, the debug control circuitry providing debug 
messages that identify an existence of a DMA channel transfer boundary for at least 
one predetermined channel. The debug control circuitry further includes a 
programmable control mechanism for selecting which of the channels of information 
controlled by the direct memory access device that the debug messages will identify 
the existence of channel transfer boundaries. One of the debug messages provided by 
the debug control circuitry indicates that a channel transfer has started for the at least 
one predetermined channel. Another of the debug messages further indicates a status 
parameter of the at least one predetermined channel. In one form the status parameter 
is one of: (1) channel priority of the at least one predetermined channel; (2) a 
utilization factor of the at least one predetermined channel; and (3) whether a transfer 
error has previously occurred in connection with the at least one predetermined 
channel. In another form one of the debug messages further indicates a time latency 
associated with the channel transfer indicating system delay between the direct 
memory access device receiving a request to begin transferring information and 
actually transferring the information. In yet another form one of the debug messages 
provided by the debug control circuitry indicates that a channel transfer has ended for 
the at least one predetermined channel. In another form one of the debug messages 
provided by the debug control circuitry indicates that each of a plurality of minor loop 
iterations of the at least one predetermined channel has started. In another form one 
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of the debug messages provided by the debug control circuitry indicates that each of a 
plurality of minor loop iterations of the at least one predetermined channel has ended. 
In another form one of the debug messages provided by the debug control circuitry 
indicates periodic status of the at least one predetermined channel. Alternatively the 
system may be configured to have a plurality of system units, each of the plurality of 
system units being coupled to the communication bus. In the alternative form, the 
debug control circuitry further includes a plurality of debug modules for providing the 
debug messages, each of the plurality of debug modules being coupled to a 
predetermined one of the plurality of system units. A debug port logic is coupled to 
the plurality of debug modules for providing the debug messages to a debug port. 

In another form there has been provided a system and method of operation 
having a communication bus and a direct memory access (DMA) device coupled to 
the communication bus. The direct memory access device controls channels of 
information, each channel of the channels of information transfers information from a 
source to a destination in the system via a channel transfer. Debug control circuitry is 
coupled to the DMA device, the debug control circuitry providing debug messages 
that periodically provide at least one status parameter for at least one predetermined 
channel. In one form the at least one status parameter is at least one of: (1) channel 
priority of the at least one predetermined channel, (2) a utilization factor of the at least 
one predetermined channel, and (3) whether a transfer error has previously occurred 
in connection with the at least one predetermined channel. The debug control 
circuitry additionally provides debug messages that indicate that a channel transfer 
has started. The debug control circuitry additionally provides a debug message that 
indicates that a channel transfer has ended. The debug control circuitry is 
programmable to enable selective generation of the debug messages for each of the 
channels of information. The debug control circuitry further generates a watchpoint 
indicator that is a predetermined watchpoint condition of the at least one 
predetermined channel, the predetermined watchpoint condition being a watchpoint 
condition based upon activity of the direct memory access device. The debug control 
circuitry further generates a plurality of watchpoint indicators, each of which 
respectively indicates a watchpoint condition of a differing one of the channels of 
information. A control register stores a control signal that enables and disables the 
providing of debug messages that periodically provide at least one status parameter 
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for the at least one predetermined channel. The direct memory access device 
implements nested transfers of information within a same channel comprising a 
plurality of minor loop iterations that form a major loop iteration. The debug 
messages each comprise a multiple bit message having predetermined bit fields 
including a message type field, a channel identification field and a status information 
field. 

In another form there is provided a system and method of operation having a 
communication bus and a direct memory access (DMA) device coupled to the 
communication bus. The direct memory access device controls multiple channels of 
information, each channel of the channels of information transferring information 
from a source to a destination in the system via a channel transfer. Debug control 
circuitry is coupled to the DMA device. The debug control circuitry selectively 
provides debug messages related to operating parameters of the direct memory access 
device by being programmable on a per channel basis. The operating parameters of 
the direct memory access device include information regarding at least one of whether 
a transfer boundary occurred and periodic status information. The debug control 
circuitry further provides at least one debug message that includes latency information 
related to system delay of the direct memory access device starting a channel transfer 
after a channel transfer request is received by the direct memory access device. 

It should be apparent that various modifications may be made to the disclosed 
embodiments. For example, processor 14 may be implemented as any of a variety of 
differing types of data processing circuits for performing various types of processing 
functions. Any type of peripheral device may be coupled to processor 102 via the 
system bus, including coprocessors. The system may be implemented with any of a 
variety of differing bit sizes. Any type of storage device may be used for the 
described stores, registers and memories. The order of the fields of the messages may 
be changed in any manner. The order of the control bits in the control registers may 
be changed. 

Benefits, other advantages, and solutions to problems have been described 
above with regard to specific embodiments. However, the benefits, advantages, 
solutions to problems, and any element(s) that may cause any benefit, advantage, or 
solution to occur or become more pronounced are not to be construed as a critical, 
required, or essential feature or element of any or all the claims. As used herein, the 
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terms "comprises," "comprising," or any other variation thereof, are intended to cover 
a non-exclusive inclusion, such that a process, method, article, or apparatus that 
comprises a list of elements does not include only those elements but may include 
other elements not expressly listed or inherent to such process, method, article, or 
apparatus. The terms a or an, as used herein, are defined as one or more than one. 
The term plurality, as used herein, is defined as two or more than two. The term 
another, as used herein, is defined as at least a second or more. The terms including 
and/or having, as used herein, are defined as comprising (i.e., open language). The 
term coupled, as used herein, is defined as connected, although not necessarily 
directly, and not necessarily mechanically. 
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